Various government and private programs provide clients with supplemental food benefits based on those clients individual nutritional needs.
Many support programs are grant programs. The food benefits granted to clients include specific food items with the amount of food items indicated by non-monetary values. For instance, a client's benefits could consist of several gallons of milk, several pounds of carrots, several pounds of cheese and a quantity of beans. A food benefits grant system is an example of many U.S. Government entitlement programs.
The traditional method of delivering program benefits to clients is for a government agency to provide paper vouchers (or checks) that list the quantities of food items granted. The client presents the voucher to an authorized retailer in exchange for the food items listed on the voucher. The retailer then manually enters the cost for the food items onto the voucher and submits it to the government agency (or its third-party processor) for payment.
Some government and private agencies have attempted or are attempting to convert to an electronic method of delivering these benefits. Two general approaches have been used: on-line and off-line.
The on-line method used a model not unlike traditional debit and credit transaction processing. However, significant challenges exist for performing transactions in an on-line environment. The “account” should be available at all points of use, requiring reliable real-time communications to all sites. Additionally, an account is much more complex than traditional debit and credit accounts as multiple, non-monetary values must be managed and processed during a transaction. This complicates the on-line messaging required to perform a transaction with the account. It remains to be seen if various government and private programs can be performed adequately using the existing transaction processing infrastructure.
Existing off-line methods typically focus on using a smart card to securely deliver benefits. The benefits are “written” to a smart card at the benefit issuance locations and are “read” from the smart card at the retailer locations. Once read at the retailer location, the food item quantities are adjusted and then the updated record of benefits is written back to the smart card. Unfortunately, this method presents a significant security concern: if the benefits are “read” from the smart card, manipulated by the retailer and then written back to the smart card, the possibility of benefits being “added” rather than “subtracted” by the retailer is a very real security risk. Problems resulting in added benefits can occur due to transaction glitches or due to intentional tampering in the retailer device. The electronic systems that are in operation today take great pains to minimize the chances of this occurring, usually by implementing complex cryptographic protocols and/or by extending their trust model to the retailer's processing equipment (payment terminals). However, this approach is problematic, as it requires these types of systems to maintain control over equipment and/or software that is not necessarily owned by the government agency, such as retail payment terminals, electronic cash register software, etc. In many cases this is not practical or cost effective.
Thus, there is a need for providing improved methods and apparatus supporting off-line non-monetary, e.g., government agency type, transaction processing. Methods and apparatus that place benefits on the smart card and use new and novel methods to minimize security risks would be advantageous. Methods and apparatus that include new approaches to preventing a retailer site from inadvertently or fraudulently adding benefits to an existing account would also be beneficial.
Various government and private agencies are attempting to develop and implement new methods of delivering food benefits to their clients. Some such agencies are pursuing an electronic benefit transfer (EBT) solution for issuing food benefits; currently, a paper-based voucher system is in place.
Some government and private agencies require a benefit account to be designed for implementation on a smart card that would be easy for retailers to interface with, while solving the security concerns present with other off-line methods.
Various known approaches to implementing systems using cards will now be discussed. The closest solutions utilize a flat-file structure smart card with limited capabilities. As a result, there are significant concerns with those solutions. To reduce the security risks associated with these cards, complex cryptographic protocols are usually implemented in an attempt to mitigate the risks. However, these protocols usually involve shared secret keys that require complex key management protocols to be implemented; and they require intervention by the retailers. It is inconvenient to have to periodically update many unconnected retailer sites at diverse locations with these secret keys. Also, since the retailer sites, equipment, and personnel with access to the retail equipment are typically not secure, the retailer equipment is subject to tampering.
In view of the above, it should be appreciated that there is a need for methods which can be used to limit the need to use complex keys and allow for management to be provided from a limited number of secure sites, yet still provided adequate security for transactions at each of the retailer sites.
In addition to the security concern issues discussed above, there is also room for improvement in the area of benefit package account structure and transaction methodology and apparatus.
The familiar method of performing transactions typically involves maintaining an account consisting of one value or balance, usually associated with a specified currency, such as dollars or pounds. This type of account (a “traditional account”) is typically maintained on a central server (in the traditional debit and credit model) at a bank or other financial entity. Alternatively, this traditional account can be maintained individually on any trusted, secure computing device, such as a smart card, Personal Digital Assistant (PDA) or Personal Computer (PC). These types of individual accounts are commonly called electronic purses. In either scenario, the account is maintained on a device that has the capacity to accept transaction requests and either approve or deny those requests.
Transactions are performed with the traditional account, usually by issuing requests to the account to “debit” or “credit” the account balance. Once received by the account, the logic implementing the account determines if the request can be approved. If it is determined that the debit or credit request can be approved, the account value (balance) is adjusted as appropriate and evidence of the successful transaction is returned to the requesting entity (an “approval”). If the request can not be approved, the account balance is unaffected and the entity requesting the transaction is notified that the transaction can not be performed as requested (a “denial”).
This basic method affecting single-value accounts is widely used, although specializations exist to accommodate implementation-specific needs, including authorization, authentication and other security concerns.
Generally, “traditional accounts”, where balance values are modified one per transaction, are appropriate for most financial transactions where only one value (or balance) is maintained and manipulated. However, there are a growing number of situations where it is advantageous to: (i) maintain two or more values in one account and (ii) perform transactions with the account affecting one or more of those values in one unit transaction.
Thus, there exists a need to be able to combine two or more related “values” into one “account” and then to transact with that account, affecting one or more of those values in a single, verifiable, unit “transaction”.
As discussed above, entitlement programs tend to be more complex to manage in that the clients do not receive money, but are provided with vouchers for different amounts of specific food items. For instance, a typical benefits package could consist of five pounds of carrots, three gallons of milk and two pounds of beans. This benefits package cannot be maintained as a single value account because there are three different values, corresponding to different units of measurement, associated with the account.
Handling multiple values has been accomplished traditionally by using multiple single value accounts which are updated in a series of separate transactions which are normally implemented sequentially. Extending the benefits example above, one could establish a traditional account for pounds of carrots, another for gallons of milk and yet another representing pounds of beans. In this scenario, a purchase of a pound of carrots, a gallon of milk and a pound of beans would be affected by performing one debt transaction with the carrot account, one debit transaction with the milk account, and one transaction with the beans account. Since each transaction is separate, the carrot transaction may be approved while the milk transaction refused, e.g., due to an insufficient amount of milk credits being available. This can lead to a portion of a purchase being approved and other portions being declined. This approach of using 3 separate transactions is not efficient since it involves multiple separate transactions involving manipulation and checking of balances and becomes even more inefficient as additional values have to be acted on.
An alternative method used to implement multiple value accounts involves moving the data representing the accounts' values from the host device to the point at which they will be changed, typically a point-of-sale (POS) device. The POS device manipulates the data, the writes the data back to the host device. In this model, the host device does not perform the transaction processing; it is essentially a storage-only device that holds the account information. As a result, the POS device must be “trusted” by the owner of the account because the POS device manipulated the data. This presents significant security concerns in situations where the POS device is not necessarily managed by the owners of the account, which is common in grant programs.
In view of the above discussion there is a need for new methods and apparatus which facilitate accounts including multiple items with associated non-monetary values representing balances. Approaches which limit the signaling between the retailer device and account storage device would be beneficial. Methods and apparatus which treat the account storage device as the trusted device, minimize retailer access to and manipulation of the account would also be useful. Accordingly, it is an objective of the invention to address one or more of the problems discussed above with implementing a system where multiple balances corresponding to one or more non-monetary units need to be maintained and updated in a secure fashion.